모의해킹의 중요 요소인 '연결 고리'를 잘 활용하여, 모의해킹의 효과를 최대화하기 위해서는 다음과 같은 단위로 모의해킹을 수행하는 것을 권한다. (하나의 예일뿐 절대적인 단위는 아니다.)
  • 네트워크 단위
  • 시스템 단위
  • 애플리케이션 단위
네트워크 단위에 대한 모의해킹 수행조직 전체 또는 일부 구역의 보안 위협을 도출하고자 할 때 적합하다. 모의해킹을 한번도 수행해보지 않은 조직이라면 적극적으로 권하는 방법이다. 보안 진단은 '전수 검사'를 수행하기 어렵기 때문에 중요도 또는 샘플링을 통해서 일부 시스템을 대상으로 한다. (요즘은 보안 컨설팅이라는 것이 많이 변질되어 SI 용역 비슷하게 전락하였다. '전수 검사'를 해준다고 하지만... 현실적으로 말이 안되는 요청이며, 제안이다. 왜 이러한 요청이 말이 안되는 지와 누구에게 책임이 있는지에 대해서는 다음에 또 언급하고자 한다.) 관리자의 무관심이나 실수 또는 규정 위반자 등의 다양한 원인으로 취약한 시스템이 방치되는 경우가 많다. 항상 보안 사고는 관리되지 않거나 예외적인 시스템으로 인해 발생한다. 따라서 시간과 비용이 많이 들더라도 1년에 한번 정도는 이러한 단위의 모의해킹을 실시하여, 외부와 내부의 중요 영역에 대해 보안 위협을 파악할 것을 권하고 싶다. 이는 조직의 보안 위험을 파악하고 사고를 예방하는 데 큰 도움이 될 것이다. 

시스템 단위의 모의해킹은 현재 주로 이루어 지고 있는 형태이다. 특정 시스템 몇 개를 선정하고 그 시스템의 보안 위협을 도출하고자 할 때 적합하다. 이 방식은 처음 모의해킹을 수행하는 조직엔 적합하지 않은 방식이다. 이는 네트워크 단위의 모의해킹을 수행한 상황에서 신규 시스템이 도입되거나 중요 시스템에 대해서 보다 깊이 있게 보안 위협을 도출하고자 할 때 적합하다. 동 네트워크에 대한 보안 점검 또는 모의해킹이 수행되지 않은 상황에서 해당 시스템에 대해서만 모의해킹을 실시하는 것은 도움이 되지 못한다. 왜냐하면, 동 네트워크의 취약한 시스템에 의해서 보안 수준이 높은 시스템도 취약하게 되기 때문이다. 취약 수준은 항상 하향 평준화됨을 잊어서는 안된다. 예를 들어 A라는 회사의 관리되지도 않고 비즈니스에 큰 비중도 차지하지 않는 시스템이 침해사고를 당했다고 해보자. 관리자 또는 회사 내부에서는 “별로 중요하지도 않은 시스템인데 뭘...”이라고 생각할지 몰라도, 언론에서는 "A 회사 해킹 사고 당해 ...”이라고 다룰 것이다. 이러한 정성적인 이유뿐만 아니라 기술적인 이유에서도, 동 네트워크의 시스템이 침해를 당한다면 스니핑, 신뢰성을 이용한 내부 시스템 침해 등 매우 심각한 보안 위협이 발생할 수 있다는 잊어서는 안될 것이다. 
시스템 단위의 모의해킹을 수행할 때도 연결 고리는 매우 중요하게 작용한다. 대상 시스텍으로 선정된 시스템의 연관성, 해당 시스템에서 구동 중인 서비스 또는 프로프램의 연관성은 보안 위협을 도출하는 데 중요한 요소가 된다. 

애플리케이션 단위의 해킹은 몇 년전부터 유행하고 있는 웹 해킹과 같은 형태이다. 특정 애플리케이션(도메인 또는 URL)을 선정 또는 지정받아 수행하는 것으로 이는 네트워크와 시스템에 대한 보안 수준이 어느 정도 보장되는 환경에 적합하다. 애플리케이션에 대한 모의해킹을 수행 할때는 애플리케이션에서 제공하고 있는 기능들이 주요 연결고리를 이용하여, 보안 위협을 도출하게 된다. 특정 기능(파일 업로드, 데이터베이스 연동, 로그인 등)의 보안 취약점으로 인해서 얼마만큼 심각한 보안 위협이 발생할 수 있는 지를 파악하는 것이 주요 포인트이다. 

이와 같이 여러 단위로 모의해킹을 수행함에 있어서 추가적으로 중요한 요소는 고객의 비즈니스이다. 모의해킹은 보안 위협을 도출하기 위한 것으로 단순히 기술적인 수준의 취약점만을 도출하는 것에 그쳐서는 안된다. 취약점 간의 연결고리와 더불어 고객의 비즈니스 위협이 연결되어야 보다 더 현실적인 보안 위협들이 도출될 수 있다.  

PS. 다시 한번 강조하자면, 모의해킹이란 “안전합니다”라는 보장을 받기 위한 것이 아니라, 현재 상태에 초점을 두고, 보안 취약성 간의 상호 연관성과 이로 인해서 발생할 수 있는 피해를 파악하기 위한 것임을 강조하고자 한다.  


신고
보안 컨설턴트 or Penetration Tester로서 시간이 거듭하면 할 수록 부딪치는 어려움 중에 하나는 모의해킹에 대한 인식 부족이다. 고객 뿐만 아니라 보안 컨설팅 회사, 심지어는 모의해킹을 수행하고 있는 사람들 조차 잘못된 인식의 틀을 가지고 있는 것이 현실이다. 

잘못된 인식의 틀에서 현재의 모의해킹은 많이 왜곡되어 가고 있는 것 같다. 

그 잘못된 인식 중에 하나는 바로 모의해킹을 '형식'이라는 틀에 고정 시키려고 하는 것이다. 

'해킹'이란 규칙을 깨는 것이고, 문제를 제기하는 것이며, 규정을 위반하는 것이라고 생각한다. 그런데 점점 모의해킹은 정형화되어 가고, 보안 진단과 별반 차이가 없어지고 있다.  보안 진단이란 모의해킹으로 인해 도출되는 다양한 보안 위험 중에서 그 도출 빈도수가 높고, 그 중요도가 높은 것들을 정형화하여, 이를 주기적으로 진단하고 관리하기 위한 것이다. 그런데 요즘은 모의해킹을 수행하는 방향 또는 요구하는 방향을 보면, 모의해킹을 요구하는 것인지 보안 진단을 요구하는 것인지 애매모호한 경우가 많다. 

모의해킹의 중요 요소는 바로 연결 고리를 이어하는 것이다. 즉, 개별적인 취약점들의 상호연관성과 중요도 등이 서로 맞물려서 결과가 나타날 때 모의해킹은 진정한 가치가 있다. 그런데 현실은 이와는 별 관계없이 돌아가는 것 같다. 보안업계에서 모의해킹 전담 또는 팀은 사라져가고, Generalist가 되어가고 있는 것 같다. 따라서 모의해킹은 그 목적과 특징을 충분히 살려서 좋은 결과(예상치 못한 위험이나 금전적 손실 등을 사전에 탐지하고 대응)를 도출하기 보다는, 기계적인 수행을 하고 보안진단과 별반 차이가 없는 점검을 실시하는 경우가 많다. 

애플리케이션이 어떤 기능을 가지고 있는 지 알지도 못하면서, 단순히 기술 위주의 점검을 실시한다.  스캐너의 결과를 단순히 리뷰하는 수준에 그치는 경우도 있다. 이렇게 되다보니 이제는 모의해킹을 단순히 도구(스캐너 또는 특정 공격을 위해 제작된 도구)로 수행하는 것이라고 생각하는 인식들까지 일반화되어가고 있다. 

모의해킹을 제대로 수행하기 또는 적용하기 위해서는 우선 목적이 명확해야 한다. 목적이 애매모호해지거나 두 마리 토끼를 잡으려 하는 것은 자제했으면 하는 바람이다. 앞서도 얘기를 했지만 모의해킹의 중요 요소로서 연결 고리를 잇는다는 것은 다음과 같이 설명할 수 있다. 흩어져 있는 취약점들은 보안 진단을 통해서도 충분히 도출될 수 있는 것들이 많다.(일부는 기존의 취약점 진단 방법론에서 하지 못하는 것도 있다.) 그러나 보안 진단과 모의해킹의 결과는 확연히 다르다는 것을 두 가지 서비스를 받아본 사람이라면 느낄 것이다. 그 차이는 바로 연결 고리에서 나온다. 보안 진단은 개별 시스템에 초점이 맞춰져 있는 반면, 모의해킹은 단계별(정보 수집->권한획득->권한 오용 또는 상위 정보 획득)로 필요한 취약점들을 연결에 연결을 시키는 것이다. 취약점은 굳이 시스템적인 것에 한정되지 않으며, 취약점은 단순히 목적을 이루기 위한 수단에 지나지 않는다.

예를 들어 설명하자면, 서버 A와 서버 B를 대상으로 보안 진단과 모의해킹을 실시했을 경우, 보안 진단에서 아래와 같이 도출된 취약점들이 모의해킹에서는 다른 결과를 나타낼 수 있다는 것이다. 보안 진단의 결과에서는 큰 보안 위험으로 다가오지 않는 결과이지만, 모의해킹을 수행한 결과로서는 매우 심각한 보안 위험이었음을 알 수 있다. (아래와 유사한 사례를 직접 경험한 적이 있음을 강조하고자 한다.) 
  • 보안진단
    • 서버 A: 불필요한 서비스 존재 
    • 서버 B: 불필요한 파일 존재
  • 모의해킹
    • 서버 B에서 획득한 정보를 바탕으로 서버 A의 telnet 서비스를 통해 시스템 관리자 권한을 획득하고, 신뢰 관계에 있는 서버 B의 일반 계정을 획득함.
모의해킹의 중요 요소인 '연결 고리'에 대해 문제를 제기하는 수준에서 이 글은 마감을 하고, 다음 글엔 바람직한 모의해킹 수행 방안을 얘기해보고자 한다. 

PS. 이전에도 언급을 했지만 이 글은 보안 진단과 모의해킹 중 어느 것이 낫다는 것을 말하고자 하는 것이 아니다. 보안 진단은 보안 진단으로서의 장점과 역할이 있으며, 모의해킹은 모의해킹으로서의 장점과 역할이 있다. 이를 충분히 알리고 컨설턴트는 컨설턴트로서 제대로 된 서비스를 하고 고객은 이를 통해 안전한 서비스 제공을 할 수 있었으면 하는 바람이다. 
신고

보안 서비스에 대한 진정한 소비자는 누구일까?

시간이 지나면서 보안에 대한 마인드와 가치가 많이 변화했다. 항상 피부로 느끼면서 고민스러운 문제이다.

처음에는 웹 서비스는 단지 기업의 홍보를 위해 사용되었다. 이제는 웹 서비스가 잠시라도 중단이 된다면 기업의 신뢰성뿐만 아니라 수익에도 엄청난 영향을 미칠 정도로 그 중요성은 커졌다. 웹 서비스는 이미 비즈니스의 중심에 서 있다. 기술의 발전 역시 많은 것을 바꾸어 놓았다. 그 중에서 중요한 한 가지는 정보가 서버에서 각 개인의 PC로 이동되었다는 것이다. 이에 따라서 침해의 대상도 슈퍼 컴퓨터와 같은 중앙 집중적인 서버에서 개인의 PC로 이동되었으며, 그 이동은 시간이 흐를 수록 가속화 되고 있다. 이제는 정보 또는 서비스의 가장 끝단에 있는 고객들의 정보가 보안의 최대 관심사가 되고 있다.

이런 시점에서 보안에 대한 관점도 변화하고 있다. 과거에는 서비스 제공자에 국한되어 바라보던 시각이 최종 소비자에게로 쏠리고 있다. 이러한 변화 속에서 딜레마를 느끼게 된다. 보안 서비스에 대한 돈을 지불하는 것은 서비스 제공자이지만, 우리가 보호해야 하는 것은 서비스 이용자들의 정보이다.

보안 서비스를 제공하는 입장에서 누구의 입장 또는 보안을 고려해서 대응방안을 도출해야 할까?

한 예로 이러한 고민을 하게 된 계기를 얘기하고자 한다.

웹 서비스에 대한 비밀번호 설정과 관련해서 아래와 같은 권고를 흔히 볼 수 있다.

“웹 계정의 비밀번호는 영문자, 숫자로 구성되어 6~8자리 이상으로 설정하여야 한다.”

과연 이러한 보안 권고가 올바른 것일까? 시스템 계정의 비밀번호 구성과 달리 웹 계정의 비밀번호 구성은 특수문자의 사용을 자제하고 있다. 그 이유는 특수문자의 사용을 허용함으로 인해서 각종 보안 취약점이 발생할 가능성이 존재하기 때문이다. 우리가 흔히 듣는 SQL Injection, Command Injection, Directory Traversal 등의 보안 취약점이 개발자가 미처 생각하지 못한 특수 문자에 의해서 발생하는 것이 원인이다. 특수 문자의 사용을 금지함으로써 불확실한 위험으로부터 서비스를 보호할 수 있다. 사이트의 보안을 강화하기 위해서는 불확실함이 존재하는 특수문자를 사용하지 않아야 한다.

개인의 보안 관점에서 보면, 이러한 입장은 달라진다. 개인으로서는 영문자, 숫자 이외에 특수문자까지의 선택의 다양성이 주어졌을 때 보다 안전하게 보호 받을 수 있다. 영문자는 26개(대소문자를 구별한다면, 52개)이며, 숫자는 10개, 우리가 키보드를 통해서 입력 가능한 특수문자는 33개(스페이스 포함)이다. 영문자와 숫자로만 구성되어 있다면, 62가지의 선택이 한 자리 당 존재하며, 6자리의 비밀번호를 설정할 경우 56,800,235,584개의 조합이 가능하다. (8자리라면, 2.1834010558 x 10^14) 특수문자가 허용된다면, 62가지 선택에서 95가지의 선택으로 확장되며, 6자리일 때 735,091,890,625의 조합이 가능하다. (8자리일 때는 6.6342043129 x 10^15) 6자리의 경우 특수문자를 허용하는 것과 하지 않는 것으로 인해서 발생하는 조합의 차이는 13배가 나며, 8자리일 때는 30배의 차이를 나타낸다.

보안 서비스의 최종 소비자인 일반 사용자를 생각하면, 특수 문자를 포함하여 비밀번호를 설정하도록 하는 것이 올바르다. 대신 여기에는 입력값 검증을 철저히 할 수 있다는 보증이 따라야 한다. 만약 이러한 보증을 하지 못한다면, 최종 사용자의 정보는 사이트의 침해사고로 인해서 허무하게 무너질 수 있다.

현재 일부 대형 포탈들을 포함하여 개인의 비밀번호 설정에 대해서 특수문자를 배제하는 곳이 일부 있다. 이러한 움직임은 사용자의 정보를 잘 보호하기 위한 움직임이라고 할 수 있다. 아직은 웹 보안이라는 것이 새로운 기술들이 계속 나오는 급변하는 환경 속에 있다 보니 정형화 되기가 힘든 측면이 있다. 따라서 개인들은 제한된 환경 속에서 자신의 정보를 철저히 지키기 위해서는 최소한 8자리 이상의 비밀번호를 설정하기 바란다. 특수 문자가 배제된 환경에서 8자리의 비밀번호 조합은 6자리의 비밀번호 조합보다 3,844배나 높은 강도를 제공한다.

보안 서비스 제공자로서 1차 서비스 이용자와 2차 서비스 이용자 중 누가 우리의 진정한 고객인지는 시간이 지나면 지날 수록 고민스러운 문제가 될 것이다. 이 글에서 예로 든 비밀번호의 설정 외에도 대응방안이나 서비스를 제공할 때 2차 서비스 이용자의 보안까지도 고려해야 하는 대안들이 앞으로 꾸준히 등장하리라고 생각한다.

신고
이전 1 다음

티스토리 툴바