한빛출판네트워크

제로데이라는 의미 두개를 생각해볼 수 있다. 첫째는 고객사의 새로운 취약점으로 정의할 수 있다. 고객사 입장에서 보면 이제까지 보고되지 않았던 취약점들은 모두 제로데이라고 할 수 있다. 서비스 진단을 받아 2개의 취약점이 도출되어 대응을 하였는데, 다음년도에 다시 다른 취약점들이 도출되면 서비스 차원에서는 모두 제로데이라고 할 수 있다.

두번째는 질문자가 생각하는 모든 운영체제, 애플리케이션, 데이터베이스 등에 CVE가 등록되지 않은 취약점들을 의미한다. 서비스 개발자들의 프로그래밍 버그의 문제가 아니라, 벤더사에서 제공되는 시스템들에 대한 버그라고 할 수 있다. 대부분 모의해킹 진단을 하게 되면 앞쪽에서 소개한 취약점들이 대부분이다.

업무시간에 순수 제로데이를 찾아야 하는 사례는 있다. 업체에서도 오픈소스를 이용해 업무프로세스에 대입한 경우가 많다. 최신배포버전을 사용한다고 하더라도 취약점은 존재할 수 있다. 이런 프로젝트에 투입되면 온전히 제로데이 찾는것에 집중할 수 있지만 그 작업이 만만치 않다. 

취약점들이 발견되면 고객사에서 결과보고서를 받아 벤더사에 업데이트 요청을 할 수도 있고, 진단자 회사이름이나 진단자이름으로 벤더사에 취약점보고서를 건내준다. 회사마다 어떤 보고체계를 가지고 있냐에 따라 다르기 때문에, 그에 맞게 대응하면 된다. 나도 국내외 벤더사 대상으로 여러 취약점을 찾았지만, 저자 이름으로 공개된것은 딱 한개였다.

지금은 버그헌트 프로그램도 많이 생겼고 포상금도 자연스럽게 따라오는 분위기였지만 몇년전만 하더라도 아주 적은 벤더사에 한해서만 진행되었다. 국내에서도 구글사(크롬브라우저) 대상으로 취약점을 보고하여 3만달러(한화 3천만원정도)를 포상받은만큼, 업무에서 발견된 제로데이 취약점에 대해 회사와 잘 협의할 필요는 있다. 

제일 중요한 것은 새로운 취약점을 찾아낼 정도의 역량강화 시간을 지원받을 수 있는 환경이 중요하다. 내가 다녔던 컨설팅 회사에서는 프로젝트에 투입이 되지 않으면, 내부 역량강화 시간을 가졌다. (책임급이 되니 제안서 작성에 더 투입이 되었지만...) 이 시간에는 자유롭에 연구주제를 선택하고 결과는 팀원들에게 공유하는 형태였다. 이때 발견한 제로데이 취약점은 대부분 회사 이름으로 보도되었다.