모의 침투 테스트

보안을 확인하는 가장 싼 방법은 자동 검사 도구를 돌리는 것입니다. 코드와 서비스를 훑어 알려진 패턴을 찾아 주고, 배포마다 돌릴 수 있어 비용도 거의 들지 않습니다. 이 단계에서 잡히는 것이 꽤 많습니다.

문제는 도구가 아는 것만 찾는다는 데 있습니다. 페이지덱에서 그 한계가 드러난 일이 있습니다. 공유 링크로 들어온 사람이 문서 주소 끝의 번호를 하나 바꿔 보니 다른 팀 문서가 열렸습니다. 그 화면은 자동 검사에서 아무 문제 없다고 판정된 상태였습니다.

이유는 단순했습니다. 코드에 문법적 결함이 없었고 알려진 공격 패턴도 아니었기 때문입니다. 요청한 사람이 그 문서를 볼 자격이 있는지 확인하는 인가 검사가 한 줄 빠져 있었을 뿐입니다. 도구는 그 한 줄이 있어야 한다는 사실을 모릅니다. 그 판단은 이 제품에서 누가 무엇을 볼 수 있어야 하는지를 아는 사람만 할 수 있습니다.

사람이 목표를 정하고 시나리오를 짜서 실제로 두드려 봐야 나오는 구멍이 따로 있다는 것이 이 점검이 생긴 이유입니다.

여섯 단계로 돌아갑니다. 앞의 두 단계를 건너뛰면 점검이 사고가 됩니다.

1. 범위와 규칙을 문서로 못 박습니다. 두드려도 되는 주소와 계정, 하지 말아야 할 행위, 기간, 문제가 생겼을 때 연락할 창구를 적습니다. 하지 말아야 할 행위에는 실제 고객 데이터를 지우는 일과 서비스를 멈추게 하는 부하 공격이 대개 들어갑니다. 이 문서가 없으면 점검하는 쪽도 법적으로 위험하고, 받는 쪽도 어디까지가 점검이고 어디부터가 실제 침입인지 가릴 수 없습니다.
2. 정보를 얼마나 줄지 정합니다. 아무 정보 없이 외부에서 시작하는 방식, 계정과 문서 몇 개를 받고 시작하는 방식, 코드까지 보고 시작하는 방식으로 나뉩니다. 기간이 2주로 정해져 있다면 가운데가 실용적입니다. 아무 정보 없이 시작하면 첫 주를 입구를 찾는 데 쓰게 되고, 공격자는 우리와 달리 시간 제한이 없습니다.
3. 시나리오를 짭니다. 도구를 먼저 돌리지 않고 무엇을 지키고 싶은지에서 시작합니다. 다른 팀 문서를 열 수 있는지, 무료 계정이 유료 기능을 쓸 수 있는지, 탈퇴한 구성원이 아직 들어올 수 있는지 같은 문장으로 적습니다.
4. 두드립니다. 웹에서 가장 많이 터지는 취약점을 모아 둔 OWASP Top 10을 점검표로 먼저 훑고, 그다음에 이 제품에만 있는 권한 구조로 넘어갑니다. 앞은 도구와 겹치는 구간이고 뒤가 이 점검의 값이 나오는 구간입니다.
5. 보고서를 받습니다. 항목마다 넷이 들어 있어야 씁니다. 재현 절차, 실제로 무엇을 할 수 있었는지, 심각도, 권고입니다. 재현 절차가 빠진 항목은 고칠 수 없습니다. 어떤 요청을 어떤 순서로 보냈을 때 무엇이 보였는지가 적혀 있어야 개발이 같은 상태를 만들어 확인할 수 있습니다.
6. 고치고 같은 항목만 다시 확인합니다. 여기까지가 한 회차입니다. 재확인을 건너뛰면 고쳤다고 적힌 항목이 실제로 막혔는지 아무도 모르는 상태로 다음 해까지 갑니다.

맞는 때가 넷입니다. 구조를 크게 바꾼 뒤, 결제나 권한처럼 잘못되면 되돌리기 어려운 기능을 열기 전, 기업 고객이 계약 조건으로 요구할 때, 그리고 1년에 한 번쯤 정기로 돌릴 때입니다. 세 번째가 실무에서 가장 많습니다. 수아가 기업 고객과 계약을 쓸 때 최근 점검 보고서를 요구받는 일이 잦습니다.

안 맞는 때도 분명합니다.

1. 코드가 매주 크게 바뀌는 초기 — 점검한 다음 주에 화면이 절반 바뀌면 보고서의 절반이 쓸 수 없게 됩니다.
2. 자동 검사로 걸러질 기본 항목이 널려 있을 때 — 그 상태에서 사람을 부르면 비싼 시간이 도구가 할 수 있는 일에 쓰입니다. 먼저 정리한 뒤에 부릅니다.
3. 예산이 화면 두세 개를 보는 데 다 드는 규모 — 범위가 너무 좁으면 보고서가 나와도 그 밖이 여전히 비어 있습니다.

한계는 셋입니다. 첫째, 결과는 그 시점의 사진입니다. 다음 배포에 새 구멍이 생길 수 있어서 통과했다는 사실이 지금 안전하다는 뜻은 아닙니다. 둘째, 범위 밖은 보지 않습니다. 관리자 화면을 범위에서 뺐다면 그 화면에 대해서는 아무것도 확인된 것이 없습니다. 셋째, 결과가 사람의 실력에 달려 있습니다. 같은 서비스를 두 팀이 점검하면 찾아내는 항목이 겹치면서도 서로 다릅니다.

"다음 달에 모의 침투 들어갑니다. 범위 문서 먼저 확정하죠."

두드려도 되는 대상과 금지 행위를 못 박고 시작하자는 말입니다.

"이 항목은 재현 절차가 없어서 못 고칩니다."

보고서에 필요한 내용이 빠졌다는 지적입니다.

"통과했다고 안전한 건 아니에요. 범위가 결제 화면까지였습니다."

점검의 결론이 어디까지 적용되는지 분명히 하는 말입니다.

페이지덱은 1년에 한 번 정기로 돌리고, 결제와 권한을 크게 손댄 뒤에 한 번 더 돌립니다. 태오가 범위 문서를 쓰고 규원이 승인합니다. 보고서가 오면 태오가 항목을 심각도순으로 늘어놓고, 그중 데이터가 새 나가거나 남의 문서가 보이는 종류는 다음 배포에 바로 넣습니다. 나머지는 기한을 적어 목록에 남깁니다.

기한을 적는 일이 실제로 값을 합니다. 심각도가 낮은 항목은 적어 두지 않으면 반년 뒤 같은 보고서에 같은 항목으로 다시 올라옵니다.

통과하면 안전하다고 읽는 경우가 가장 많습니다. 외부 전문가가 두드려 보고 문제를 못 찾았다니 그렇게 보입니다. 하지만 이 점검이 말해 주는 것은 정해진 범위를 정해진 기간에 두드려 이만큼을 찾았다는 사실뿐입니다. 범위 밖과 점검 이후는 포함되지 않습니다. 보고서를 안전 증명서로 읽으면 다음 분기에 새로 붙인 기능을 아무도 다시 보지 않게 되고, 그 기능이 다음 사고의 자리가 됩니다.

만든 사람이 직접 하면 된다고 보는 것도 흔합니다. 제품을 가장 잘 아는 사람이 가장 잘 찾을 것 같지만, 만든 사람은 자기 가정 안에서 두드립니다. 이 화면은 로그인한 사람만 온다는 전제로 만든 사람은 로그인하지 않고 그 주소를 직접 여는 시도를 떠올리기 어렵습니다. 밖에서 온 사람이 값을 하는 이유가 실력보다 이 전제의 부재에 있습니다.