최근 들어 보안 사고가 ‘주요’ 미디어 매체를 통해 자주 오르내리고 있다. 수 년전까지만 해도 주요 미디어 매체가 아닌, 전문 미디어 매체 정도에서만 보안사고를 언급했던 점을 떠올린다면 이제 보안 사고는 전 국민이 관심을 가지는 이슈로 급부상했다고 볼 수 있다.
국내에서 발생한 보안사고들의 대부분은 IT시스템(이 칼럼에서는 서버, 네트워크장비, 어플리케이션과 같은 IT조직의 운영대상을 지칭한다.)과 직간접적으로 연관되어 있다. 외부 해커에 의해 발생된 보안사고는 직접적으로 IT시스템을 통해 정보를 유출해서 발생하고 있고, 외부의 해커가 아닌 내부직원이 고객정보를 대량으로 유출한 보안 사고의 경우는, 최초에 IT시스템을 통해 한꺼번에 고객정보를 내려 받은 후 여러 경로를 통해 외부로 유출한 경우가 대부분이다.
따라서, 대부분의 IT조직들은 전사의 보안부서와 IT시스템을 통한 보안사고를 막기위한 여러가지 방법들을 고민해오고 있다.
그러나, IT시스템을 둘러싼 보안사고를 해결하기 위해서 IT조직들이 선택한 방법들을 살펴보면, 면밀한 IT내부프로세스를 살펴보는 것보다는 보안장비 도입과 같은 투자에 의존하는 경향을 보이는 경우가 종종 발견되고 있다.
이번 칼럼에서는 IT시스템이 보안의 취약점을 노출할 수 밖에 없는 IT조직의 내부 상황을 들여다보고, 이를 해결하기 위한 방법에 대해 살펴보기로 하자.
■‘변화’에 취약한 IT시스템들
최근 대부분의 IT조직들은 IT시스템에 대한 보안 취약점을 없애기 위해 정기적으로, 취약점툴을 통한 취약점 점검 활동을 하고 있다. 취약점툴을 통해 정기적으로만 취약점 점검을 한다면, 더이상 보안취약점이 발생하지 않을까?
당연히 대답은 ‘아니오’이다.
IT조직내에서 운영하고 있는 IT시스템은 ‘정지’해있는 게 아니라 계속 ‘변화’하기 때문이다. 새로운 IT시스템이 들어오고, 기존의 IT시스템은 수정과 추가등을 통해, 물리적인 외양과 내부 프로그램 또는 설정 값들이 계속 바뀌고 있다.
IT조직들이 이런 ‘변화’가 발생하는 시점에 IT시스템의 취약점을 ‘즉각’ 제거하지 못한다면, 다음 번 취약점 점검활동을 수행할 때까지는 취약점을 고스란히 가지고 있을 수 밖에 없다.
IT시스템의 ‘변화’가 보안사고에 어떤 영향을 미치는 지를 이해하고 있지 못하는 IT조직의 상위 관리자들은, 본인이 투자를 승인한 ‘취약점툴’의 도입만으로 IT시스템의 보안취약점이 완전히 제거될 것이라는 ‘오해’를 하고 있다.
■소홀히 다루는 테스트시스템들
IT시스템들 중에는 테스트 시스템들이 존재한다. 본디 테스트용도로만 사용되는 것도 있고, ‘운영’상태로 가기 위한 전 단계로 잠깐 테스트에 머물러있는 경우도 있다. 이러한 테스트시스템들은 대체로 보안취약점을 가지고 있는 경우가 많다.
IT조직들은 대부분 이 사실을 알고 있다. 하지만 이들 IT조직들은 문제가 없을 것이라고 주장한다. 왜냐하면 본인 IT조직에는 ‘테스트환경과 운영환경의 분리’ 원칙이 엄격히 적용되어 있으며, 테스트시스템이 해킹당하더라도 운영환경으로 접근할 수가 없다라는 것이다.
그러나 IT조직을 관찰해본 결과, 이것이 표면적인 원칙으로만 작동하고 있는 경우를 많이발견할 수가 있었다. 특히 ‘운영’상태의 전 단계로 테스트상태에 머물러 있는 IT시스템의 경우, 가끔 운영환경에서 네트워크에 물린채 방치하는 경우가 발견된다.
또, 테스트환경이 물리적으로는 분리되어 있는 것처럼 보이지만, 실제로는 테스트시스템을 경유해서 운영시스템으로 접근할 수 있는 IT담당자만의 ‘숨겨진’ 경로를 가지고 있는 경우도 많이 있다.
변경프로세스와 보안활동과의 ‘결합’
IT시스템의 ‘변화’ 때문에 노출되는 보안 취약점을 근본적으로 제거하기 위해서는, IT조직이 모든 ‘변화’ 를 지배해야만 한다. 사소한 IT시스템의 변화라도 보안취약점을 새로이 노출시킬 수 있는지를 확인해야 한다는 얘기다.
IT조직들은 일반적으로 IT시스템의 모든 변화를 통제하기 위해 ‘변경프로세스’를 갖추고 있다. 그러나 대부분의 IT조직들은 이 프로세스의 목적을 ‘기능 구현’과 ‘장애 방지’에만 초점을 맞추고 있다. 기존의 변경프로세스의 목적에 ‘보안취약점 제거’라는 목적만 하나 더 얹는다면, 변경프로세스 하나만으로 IT시스템 변화에 따른 보안 문제를 간단하게 해결할 수 있다.
여기에는 당연히 하나의 전제가 붙는다. 변경프로세스를 통해, IT시스템의 사소한 변화를 포함하는 모든 변화가 다루어져야 한다는 점이다. ‘임의’로, 또는 ‘알려지지 않는’ IT시스템의 변화가 IT조직내에 존재한다면, 백약이 무효일 수 밖에 없다.
■IT ‘영역’에 들어올 때부터 보안취약점 제거
테스트시스템으로 인한 보안취약점 노출을 방지하는 방법은 간단하다. 테스트용도건 아니건 같에 모든 IT시스템이 IT영역에 ‘진입’하는 시점을 기준으로 보안취약점 제거활동을 수행하면 된다.
서버와 네트워크 장비같은 하드웨어성 IT시스템이 IT영역으로 들어오는 경우, 일반적으로 ‘품의->구매검토->구매->입고->설치->운영’의 순서로 진행된다. IT영역에 들어올 때부터 보안취약점을 제거해야 한다는 것을 좀더 정확하게 표현한다면, ‘입고’와 ‘설치’ 사이, 즉 최소한 네트워크에 물리기 ‘이전’이어야 한다는 것이다.
새로운 어플리케이션이 프로젝트를 통해서 도입되거나 패키지로 구매되는 경우도, 동일한 원칙이 적용된다. 네트워크에 물려서 어플리케이션의 접근을 허용하는 시점 이전에 보안취약점을 제거해야 한다.
IT보안의 수준이 높은 IT조직은 어플리케이션이 오픈되기 훨씬 이전인, IT프로젝트가 태동하는 시점부터 엄격한 보안절차를 적용하기도 한다.
■IT보안, 투자와 프로세스의 균형
IT보안의 문제는 IT조직의 내부 프로세스와 깊은 관련이 있다. IT조직의 프로세스가 부실한 IT조직은, IT보안의 문제점이 산적해 있을 수 밖에 없으며, 해결 방법도 딱히 없다. 그래서, 내부나 외부에서 IT시스템과 관련된 보안사고가 발생하게 되면, 이들 IT조직들은 보안장비에 대한 투자에만 이해당사자의 관심을 유도해나가는 경향이 있다.
물론 투자를 통해 좋은 보안장비가 도입된다면, 보안취약점 제거에 큰 몫을 담당할 수 가 있다는 점은 누구나 인정하고 있는 사실이다. 하지만, 보안사고는 늘 우리가 관심을 가지고 있고 우리 손안에 있는 것에서 발생하는 것이 아니라, 예외에서 발생한다는 사실을 알아야 한다.
IT조직내에서 예외를 최소화하고 대응하는 것은 보안툴의 몫이기보다는, 사람이나 프로세스의 몫일 가능성이 크기 때문이다.
*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.
