한빛출판네트워크

기업에서 모의해킹 의뢰가 들어와서 모의해킹을 진행했을 때, 보안장비나 시큐어 코딩 등이 잘돼 있어서 취약점을 발견하지 못했을 때는 어떤 식으로 대처하시나요?

컨설턴트로 수행했던 경험, 관리자 실무로 진행을 했던 경험으로 봤을 때 취약점이 전혀 나오지 않았던 기억은 없었습니다. 나오지 않으면 나올 때까지 야근을 하더라도 했던 거 같습니다. 시큐어 코딩이 모든 애플리케이션 취약점을 대응할 수는 없습니다.

개발단계부터 취약점을 없애기 위해 소스코드 진단을 포함해서 많은 활동을 하는 곳도 있지만, 소스코드 진단에서 찾을 수 없는 문제들이 있습니다. 이 문제로 인해서 취약점이 도출되는 경우가 어디 간에 반드시 생깁니다. 디렉터리 리스팅 및 에러처리 미흡(소스코드에서도 처리할 수 있음)같이 서버설정으로 차단할 수 있는 부분이 이에 해당합니다. 이 취약점들은 서비스 환경에 따라 큰 위협을 가할 수도 있습니다.

서비스 프로세스를 정상적으로 접근하다가 우회하는 방법들도 코드 분석에서 찾아내기는 힘듭니다. 애플리케이션 진단을 할 때 많은 비율을 차지하는 인증처리나 접근권한 미흡 등이 이에 포함됩니다. 소스코드 분석을 할 때 소스코드 내 인증 처리하는 부분의 패턴을 별도로 대입하지 않는 이상 이는 모의해킹 점검에서 많이 발생합니다.

이외에 외부에서 개발된 솔루션에서도 많이 발생합니다. 외부 솔루션은 개발단계 보안성 검토를 할 때 예외가 되는 경우가 많습니다. 진단해서 취약점을 찾아낸다고 하더라도 서비스가 오픈한 후에 꾸준한 취약점이 도출되기 때문에 정기적인 진단 및 패치가 필요합니다. 오픈소스를 기반으로 한 솔루션이라면 취약점은 더욱 많이 공개되며, 공격코드도 빨리 배포가 되어 대응하는 입장은 아주 힘들어지고, 공격하는 입장은 매우 쉽게 취약점을 도출할 수 있습니다.

또한, 소스코드 진단항목은 수백 개의 취약점 항목이 포함되어 있지만 이를 모두 적용하지 못하는 사례도 있습니다. 코드품질을 목적으로 한 항목들도 많아 개발자들이 이 항목까지 많은 자원을 투입하는 것을 꺼리는 경우도 있습니다. 이 항목들을 모두 표시하며 서비스에 적용 여부를 결정하는 과정이 쉽지 않습니다. 업체에 컨설턴트를 받는다 하더라도 100% 항목을 최적화해서 사용을 위해서는 많은 시간과 인력이 필요합니다.

기간 내에 최선을 다함에도 불구하고 취약점을 도출할 수 없다면? 이 경우에 보고서에 "취약점 발견되지 않음"이라는 결과만 기재하면 성의 없는 결과서라고 판단합니다. 보고서 내에는 어떤 점검항목들을 점검했고, 어떤 접근방식을 사용했는지 포함하는 게 좋습니다. 담당자는 어떤 취약점이 신규로 나올지 궁금도 하지만, 진단이 제대로 되었는지가 더 중요합니다. 결과보고서를 리뷰하면서 담당자들이 다른 접근을 요청할 수 있으며, 자신들이 업무에 반영한 프로세스가 올바르게 되었는지 판단할 수 있는 증거이기도 합니다.