소규모로 시작
전에도 언급했지만 다시 살펴볼 가치가 있습니다. 프로그램을 '공개'하여 전 세계에 알리고, 사내 프로그램의 경우 프로그램 정책 및 보고서 제출 양식에 공개적으로 액세스할 수 있도록 하여 공개하고 싶을 수 있습니다. 소규모로 시작하여 확장할 기회가 없으므로 위험할 수 있습니다. 아무리 준비했더라도 VDP를 출시하면 항상 놀라움이 발생합니다. 예상보다 많은 취약점이 수신되어 따라잡지 못할 수도 있습니다. 팀의 절반이 아파서 버그 분류를 할 수 없을 수도 있습니다. 인증된 스캔을 실행하는 것을 잊었는데 연구원이 실행하려고 하면 100,000개의 새 계정이 생성되어 시스템에 실수로 넘칠 수 있습니다. 예상치 못한 것이 무엇이든 소규모로 시작하여 시간이 지남에 따라 프로그램을 천천히 확장하는 것이 좋습니다. 문제가 발생할 수 있으나 이는 완전히 정상이지만 이러한 문제를 한 번에 하나씩 처리할 수 있는 대역폭을 확보하는 것이 가장 좋습니다.
자체적으로 프로그램을 구축하기로 결정했다면 웹사이트에 프로그램 정책 및 신고 제출 양식을 표시하는 것이 좋으며 해커가 로그인해야 볼 수 있도록 하는 것이 좋습니다. 서드 파티 플랫폼을 사용하는 경우 플랫폼에서 소규모 보안 연구원 초대가 자동으로 처리됩니다. 두 경우 모두 다음과 같이 비공개 VDP에 해커를 초대하는 데 사용할 초대 템플릿을 만들 수 있습니다.
안녕하세요. <조직 이름>에서 비공개 VDP에 초대하고자 합니다. VDP 프로세스를 기반으로 빌드하여 보안 연구자에게 가능한 최고의 환경을 제공할 수 있도록 소규모 비공개 모드로 시작합니다. 테스트 가이드라인과 범위는 프로그램 정책을 확인하세요. VDP 초기 단계에 의견이 있으면 알려주세요.첫 번째 연구원이 초대되고 프로그램 액세스 권한이 부여되면 보고서가 수신되기 시작합니다. 또는 아무 보고서도 수신되지 않지만 괜찮습니다. 5명의 보안 연구원을 초대한다고 가정해 보겠습니다. 둘 중 두 명이 너무 바빠서 프로그램을 전혀 보지 않기로 결정하는 것일 수 있습니다. 다른 친구가 휴가 중이며 초대 메시지를 완전히 놓쳤을 수 있습니다. 4번째와 5번째 해커는 1~2일 동안 테스트를 진행하면서 취약점을 찾지 못했습니다. 몇 주 후에 다시 방문하여 무언가를 보고할 수도 있지만 이 모든 작업을 진행하면서 초대장을 보내고 어떤 보고서도 받지 못하는 것은 여전히 충격적일 수 있습니다. 이런 일이 발생하더라도 걱정하지 마세요. 이는 지극히 당연한 일이며 소규모로 시작하여 확장해야 하는 이유입니다. 5개의 초대를 보냈지만 보고서 양이 많지 않으면 다섯 개, 5개, 10개, 심지어 20개까지만 전송합니다. 서드 파티 플랫폼을 사용하는 경우 원하는 보고서 양에 따라 시간이 지남에 따라 천천히 해커를 초대하는 자동화 메커니즘이 있습니다. 반면에 5명의 보안 연구원만 초대한 후에 다수의 취약점 보고서를 받는 경우, 보고 볼륨이 줄어들 때까지 더 많은 보안 연구원을 초대하는 것을 미루는 것이 좋습니다.
분류 및 반복
VDP를 출시한 후 처음 1~2주 동안은 들어오는 취약점 보고서를 분류하고 버그를 신고하며 연구원과 커뮤니케이션하기 위해 2명 이상의 직원이 동시에 근무하는 것이 좋습니다. 일반적으로 프로그램이 시작될 때 신고 건수가 크게 증가하다가 시간이 지나면 사라집니다. 수신되는 취약점 보고서를 분류할 때 해커의 의견을 받고 프로그램 정책의 허점이나 오해를 파악할 수 있습니다. 프로세스 및 도구에도 문제가 있을 수 있습니다. 소규모로 시작하여 이 처음 몇 주 동안 팀으로부터 많은 관심과 에너지를 받아, 이 시간을 활용해 프로그램을 빠르게 반복하고 개선하세요. 1~2개월 후에는 상황이 어지러워지고 프로그램을 원활하게 운영하게 되어 제2의 본질이 됩니다.
수직 확장, 공개 출시
팀이 프로그램 운영에 익숙해질수록 더 많은 해커가 참여할 수 있도록 초대됩니다. 알고 있는 모든 것 (존재한다는 사실을 모르고 있었을 수도 있는 애셋 포함)까지 포함하도록 범위를 확장했습니다. 결국 100명, 심지어 수백 명의 해커를 초대하는 수준에 이르렀지만 보고서 양이 줄어드는 것처럼 보입니다. 전송되는 보고서는 모두 심각도가 낮거나 중간인 것으로 보입니다. 근무 순환은 꽤 간단해 보입니다. 팀이 취약점 보고서를 분류하고 해결 단계로 푸시하며 해커와 소통하는 데 능숙합니다. 이제 프로그램을 공개적으로 출시할 준비가 되었을 것입니다. 그렇게 하기 전에 모든 이해관계자와 다시 연결하여 공개 출시를 인지하고 참여하도록 하세요. 초기 비공개 출시와 마찬가지로 공개 출시를 위한 신고 볼륨이 한 번 더 급증할 수 있는 상황에 대비하도록 팀을 준비합니다. 공개 출시와의 한 가지 주요 차이점은 누구나 개발자에게 취약점 보고서를 제출할 수 있다는 점입니다. 이렇게 하면 많은 노이즈가 발생할 수 있습니다. 예를 들어 계정에 로그인하는 방법을 잘 모르는 사용자나 스팸 봇이 양식을 작성하고 자동으로 이메일을 보내는 경우 VDP에 보고서를 제출할 수도 있습니다. 일반적인 비보안 관련 보고서를 빠르게 닫을 수 있는 템플릿을 마련하거나, 사용자를 올바른 위치로 리디렉션하도록 양식을 조정하여 이러한 상황을 미연에 방지하는 것이 좋습니다 (예: 지원 담당자가 잊은 비밀번호 등의 작업을 처리할 때). 다행히도, 일반 대중에게 프로그램을 공개하면 이전에는 연락할 방법이 없던 숙련된 해커도 이제 접근할 수 있게 됩니다. 이렇게 하면 존재하는지 몰랐던 심각도가 높거나 심각한 취약점을 발견하는 데 도움이 될 수 있습니다. 또한 글로벌 해킹 커뮤니티에서 개발자에게 직접 취약점을 공개하고 유출 및 부정적인 PR의 위험을 줄이는 등 이 가이드의 앞부분에서 언급한 모든 이점이 제공됩니다.
기념
축하합니다. 지금까지 진전을 이루셨고 이제 공개 VDP가 생겼습니다. 팀과 함께 이 과정에서 도움을 준 모든 이해관계자와 축하하는 것을 잊지 마세요. 감사를 표현하고 함께 성공을 축하할 방법을 찾는 것이 중요합니다. VDP의 공개 출시를 축하하는 것 외에도 공개 출시 기념일과 같은 주요 기록을 기념하거나 VDP를 통해 찾아서 수정한 특히 흥미롭고 중요한 버그를 강조하는 것도 잊지 마세요. 그 과정에서 측정항목을 수집하면 프로그램의 성공을 입증하고 본인과 팀의 성과를 강조할 수 있습니다.