프로그램 정책은 모든 VDP에 필수적이며 신중하게 작성해야 합니다. 프로그램 정책은 보안 연구원이 VDP에 참여할 때 가장 먼저 보는 것입니다. 프로그램의 분위기를 설정하고 기대치를 정의하며 참여하기로 한 연구자에 대한 게시자의 약속을 정의합니다.
프로그램 정책을 만들고 호스팅하는 방법
아래 가이드라인을 사용하여 VDP 프로그램 정책의 초안을 작성하세요. 프로그램 정책은 일반적으로 1~3페이지로 되어 있으며 일반적으로 다음과 같은 주제를 포함합니다.
- 연구원의 약속
- 테스트 가이드라인
- 프로그램 범위
프로그램 정책은 모든 잠재적 연구자에게 제공되어야 합니다. 초대받은 연구자에게만 VDP를 비공개로 출시할 계획이라면 프로그램 정책에 일종의 액세스 제어를 통해 초대한 연구자가 사용할 수 있도록 하고 그 외 모든 사람으로 제한해야 합니다. 또한 연구원은 보고서 추적을 위해 티켓팅 시스템에 연결된 웹 양식이나 이메일 별칭과 같은 보고서를 제출할 방법이 필요합니다. VDP의 온라인 리소스를 설정할 때 이 점을 고려하세요.
서드 파티 취약점 공개 및 버그 바운티 플랫폼은 일반적으로 다음과 같은 기능을 제공합니다.
- 정책을 생성, 수정, 게시하는 방법
- 비공개 프로그램 생성을 위한 액세스 제어
- 편안한 속도로 해커를 자동으로 초대
- 받은 보고서 처리를 용이하게 하는 받은편지함 기능
또한 서드 파티 플랫폼에서는 VDP 생성 및 출시 프로세스를 간소화하는 데 도움이 되는 다양한 컨설팅 서비스를 제공합니다. 일반적으로 서드 파티 플랫폼과 컨설팅 서비스에는 비용이 발생합니다. 서드 파티를 이용하는 경우와 사내에서 프로그램을 빌드하고 관리하는 경우의 비용과 이점을 고려하여 조직에 가장 적합한 방법을 결정하세요.
프로그램 정책에 포함할 내용에 관한 자세한 내용은 미국 법무부의 '온라인 시스템을 위한 취약점 공개 프로그램 프레임워크'를 참조하세요.
프로그램 정책 이해관계자
프로그램 정책의 초안을 작성할 때 이해관계자와 어떻게 협력할지 생각해 보세요. 여러 팀에서 정책에 포함해야 할 고려사항에 대한 의견을 제공할 수 있습니다.
| 이해관계자 | 고려사항 |
|---|---|
| 법무 |
|
| 이탈리아 |
|
| 공학 |
|
| PR |
|
| 보안 |
|
연구원 약속
연구원의 약속에는 정책에 설명된 테스트 가이드라인에 따라 선의에 따라 행동하는 연구원이 참여하겠다는 조직의 약속이 설명되어 있습니다. 예를 들어 특정 기간 내에 들어오는 모든 보안 보고서에 응답하겠다는 약속과 어떤 취약점 보고서를 수락하고 수정할지에 대한 결정을 전달합니다.
예:
<조직 이름>에서는 보안 연구원과 협력하여 Google 시스템과 서비스의 취약점을 파악하고 해결하기 위해 최선을 다하고 있습니다. 선의를 갖고 행동하고 이 정책에 설명된 가이드라인을 준수하는 한, Google은 다음을 준수하기 위해 최선을 다할 것입니다.- 영업일 기준 3일 이내에 취약점 보고서에 대한 초기 대응을 제공합니다.
- 영업일 기준 10일 이내에 취약점 보고서를 수락할지 (수정할 예정) 또는 거부 (보고서를 거짓양성 또는 허용 가능한 위험으로 식별)할지 결정합니다.
- Google에서 수락한 신고의 문제 해결 진행 상황 업데이트
프로그램 정책에 세이프 하버(Safe harbor) 문구를 채택하면 연구자가 선의의 행동을 하고 정책에 설명된 모든 가이드라인을 준수하는 한, 시스템 테스트를 위해 법적 조치를 취하지 않는다는 사실을 연구자에게 확인하는 데 도움이 됩니다.
테스트 가이드라인
테스트 가이드라인은 VDP 범위에 속하는 보안 테스트, 그리고 연구자가 피해야 하는 테스트 및 범위에 속하지 않는 테스트를 설명합니다. 연구자가 집중해야 할 특정 유형의 취약점이 있다면 이 섹션을 통해 이를 강조하는 것이 좋습니다.
예:
보안 테스트를 실행할 때 다음 가이드라인을 준수하세요.
- 내 계정 및 데이터를 대상으로만 테스트하세요 (예: 테스트 계정 만들기). 다른 사용자의 데이터에 액세스할 수 있는 취약점을 발견하면 테스트를 진행하기 전에 먼저 Google에 문의하세요.
- 실수로 테스트에서 다른 사용자의 데이터에 액세스했다면 Google에 알려 주세요. 이러한 사용자 데이터는 저장하지 마세요.
- 서비스 거부 상태가 발생하거나 프로덕션 서비스가 저하되는 테스트는 실행하지 마세요.
- 소셜 엔지니어링은 이 프로그램의 범위를 벗어납니다. 조직이나 사용자를 사회적으로 엔지니어링하려고 하지 마세요.
Google에서는 특히 다음 유형의 취약점과 영향에 관심을 갖고 있습니다.
- 원격 코드 실행
- 민감한 정보 (예: 세션 정보)에 대한 액세스를 제공하는 XSS
- 민감한 정보 또는 기능에 액세스하는 SQL 삽입
- 민감한 정보 또는 기능에 액세스하도록 초래하는 비즈니스 로직 결함
Google에서는 다음 유형의 취약점에 관심이 적으며, 이러한 유형의 취약점은
거짓양성이나 허용되는 위험으로 거부될 가능성이 높습니다.
- 상태 변경 기능이 없는 페이지에 X-Frame-Options 헤더가 없음
- 확인되지 않은 자동 검사 결과
- 악용될 가능성이 낮거나 실질적인 보안에 영향을 미치지 않는 문제
범위
범위는 연구원이 테스트할 수 있는 애셋과 VDP의 일부로 간주되지 않는 애셋을 정의합니다. 범위는 신중하게 고려해야 하며 팀에 과부하가 걸리지 않고 가능한 한 광범위하게 지정해야 합니다. 범위를 많이 포함할수록 보안 연구원의 참여를 유도할 가능성이 커집니다. 하지만 팀이 들어오는 보고서를 처리할 수 없을 정도로 범위를 너무 넓게 만들지 마세요. 범위 내의 몇 가지 애셋으로 시작합니다. 수신할 보고서 양을 더 잘 파악할 수 있게 되면 범위를 확장합니다. 시간이 지남에 따라 VDP를 공개하기 전에 모든 것을 범위에 포함하는 것을 목표로 하세요.
프로그램 정책 내에서 범위를 정의하는 방법의 측면에서 각 애셋 또는 영역에 관한 세부정보를 추가하면 보안 연구원이 개발자에게 중요한 사항과 집중해야 할 부분을 파악하는 데 도움이 됩니다. 애셋을 대상으로 안전하게 테스트하는 방법에 관한 팁도 포함할 수 있습니다. 다음 예를 참고하세요.
| 애셋 | mail.example.com |
|---|---|
| 설명 | 사용자가 이메일에 액세스할 수 있는 기본 도메인입니다. |
| 흥미로운 취약점과 영향 |
|
| 거부될 수 있는 문제 |
|
| 테스트 가이드라인 | 소유하고 있거나 테스트에 명시적 동의를 받은 계정에서만 테스트하세요. 테스트 계정을 만들 때는 사용자 이름에 'vdptest'를 포함하세요. mail.example.com/new에서 테스트 계정을 만들 수 있습니다. |
아주 자세하게 분석한 결과입니다. 또는 범위 내 애셋과 범위 외 애셋으로 이루어진 간단한 목록을 포함할 수도 있습니다.
지원 범위 내
- mail.example.com
- example.com
지원 범위 외
- blog.example.com
VDP 리소싱
VDP를 출시하려면 특정 리소스가 필요합니다. 다음을 위한 리소스가 필요합니다.
- 수신되는 취약점 보고서 검토
- 해커와의 커뮤니케이션
- 저작물 소유자 찾기 및 버그 신고
- 버그 수정
- 취약점 관리 / 해결 후속 조치
주요 이해관계자 다시 보기
아직 VDP에 대해 논의한 주요 이해관계자와의 대화를 다시 논의하여 해당 이해관계자가 VDP 출시 일정에 부합하는지 확인하고 출시에 필요한 리소스를 큐에 추가합니다. 예를 들어 엔지니어링 경영진과 협력하여 출시 후 처음 몇 주 동안 쏟아질 수 있는 보안 버그에 대비할 수 있도록 팀을 준비하는 것이 좋습니다. 보안팀 내에서는 감지 및 대응 시스템에서 알림을 분류하는 직원이 VDP 출시일을 알고 있는지 확인하고 테스트가 시작될 때를 위해 더 많은 시간과 리소스를 할당하는 것이 좋습니다. 또한 VDP의 일상적인 운영을 지원할 팀을 구성해야 합니다.
팀 구축하기
VDP를 실행하려면 적당한 양의 인터럽트 기반 운영 작업이 필요합니다. 수신되는 모든 취약점 보고서를 검토하고, 기술적으로 검증하고, 대응하고, 모든 버그를 신고하고, 상태를 추적하고, 연구자에게 업데이트를 직접 전달하려고 하면 번아웃될 수 있습니다. 대규모 보안팀이 없더라도 VDP 운용 및 실행을 도와줄 팀을 구성하는 데 도움이 될 보안 전문가를 찾아보세요. VDP의 성공에 궁극적으로 책임이 있는 정의된 '소유자' 또는 '리더'는 여전히 필요하지만 이 리더를 지원하는 팀도 필요합니다.
근무 일정 수립
리소스가 준비되고 VDP를 지원할 준비가 되면 근무 일정을 설정하여 이를 뒷받침하는 구조를 마련합니다. 원하는 대로 만들 수 있지만 주간 순환은 매우 일반적인 관행입니다. 일주일 동안 업무를 처리할 때 다음을 해야 합니다.
- 분류 - 수신되는 취약점 보고서 검토
- 취약점 관리 - 기존 취약점 제거
- 지난 근무 몇 주 동안 신고된 버그를 검토하여 심각도 표준 및 해결 일정에 따라 해결이 진행 중인지 확인합니다.
- 소유자 찾기의 팁을 활용하여 소유자가 이러한 버그 작업을 하도록 설득할 수 있습니다.
- 커뮤니케이션 - 보안 연구원에게 기존 보고서에 관한 업데이트 제공
- 연구원은 기존 보고서에 관한 업데이트를 사전에 요청할 수 있습니다. 이를 확인하고 필요에 따라 대응하세요
- 취약점이 수정되면 연구원에게 다시 전달하여 그들의 노력이 조직에 긍정적인 변화를 가져왔다는 것을 알 수 있도록 합니다. 수정사항에서 놓친 부분이 있는지 또는 어떤 방식으로든 수정사항을 우회할 수 있는지 여부를 알려달라고 연구원에게 요청하는 템플릿 언어를 포함할 수도 있습니다.
받는 보고의 수와 이러한 보고서의 복잡성, 각 근무자의 기술 및 지식에 따라 몇 시간에서 일주일까지 여러 시간이 걸릴 수 있습니다. 다음은 성공적인 근무 순환을 위한 팁입니다.
- 팀이 특별히 많은 일을 하는 주에 개입하여 업무를 지원할 준비가 되어 있는지 확인합니다.
- 적절한 핸드오프 프로세스가 마련되어 있습니다. 다음 근무자의 즉각적인 조치가 필요한 문제가 있는 경우 주말에 핸드오프 메모를 작성하거나 실시간 대화를 나눕니다.
- 모두가 자신의 근무 시간을 알 수 있도록 자동화된 일정을 만드세요. 이는 각 개인에 대해 반복되는 캘린더 항목을 만드는 것만큼 간단할 수 있습니다.
- 특히 VDP가 시작될 때 근무 중인 사람에게 다시 한번 확인하여 지금이 자신의 주간인지 기억하고 도움이 필요한지 확인합니다. 순환 시 주니어 리소스가 더 많은 경우, 더 많은 고급 리소스가 이러한 리소스와 협력하도록 하여 편안하게 느끼고 증가하면서 질문을 할 수 있도록 합니다.
- 주를 교체할 수 있는 유연한 프로세스를 마련하세요. 비상 사태가 발생하여 주중에 휴식이 필요하거나 휴가가 있는 등의 상황이 발생할 수 있습니다. 이러한 상황이 발생하면 모든 팀원의 일정에 맞춰 필요한 주를 교체하도록 팀을 독려합니다.
- 처리 방법에 관한 문서를 포함하여 처리해야 하는 업무를 요약한 근무 '요약본'을 만듭니다.
사내 및 서드 파티 중 결정
지금까지의 안내는 대부분 사내에서 VDP를 빌드하고 실행하는 것을 기반으로 했습니다. VDP를 만들고 실행하는 데 도움이 되는 다양한 컨설팅 서비스와 플랫폼이 제공됩니다. 이러한 서드 파티는 일반적으로 비용을 수반하지만 VDP를 생성, 출시, 실행하는 방법을 안내하는 데 유용할 수 있습니다. 일부 서비스에서는 수신되는 취약점 보고서를 자동으로 검토하고 해커와의 커뮤니케이션을 처리하며 유효한 보고서만 팀에 에스컬레이션하는 데 도움이 되는 분류 서비스를 제공하기도 합니다. 이 프로세스를 사내에서 빌드할지 아니면 서드 파티 플랫폼을 사용할지를 결정하는 것은 요구사항 및 사용 가능한 리소스에 따라 다릅니다. 예산은 크지만 인원은 많지 않은 경우, 서드 파티를 통해 프로그램을 운영하는 것이 타당할 수 있습니다. 그 반대의 경우, 프로그램을 직접 빌드하는 데 시간을 투자하는 것이 좋습니다.
보고서 수신
서드 파티 플랫폼을 사용하기로 한 경우 해커가 서드 파티 플랫폼을 나에게 직접 제출할 수 있는 방법이 있어야 합니다. 사내에서 프로그램을 구축하는 경우 직접 구축해야 합니다. 이는 Issue Tracker에서 티켓이나 버그를 자동으로 생성하는 이메일 주소 (예: security@example.com)이거나 프로그램 정책과 동일한 페이지에서 연결되는 필수 양식 필드가 있는 웹 양식일 수 있습니다. 형식에 관계없이 보고서를 받을 형식을 해커에게 알릴 수 있는 가장 좋은 방법입니다. 해커에게 특정 형식으로 보고서를 제출하도록 요청한다고 해서 항상 신뢰할 수 있는 것은 아니지만, 요청한다고 해서 해를 끼치지는 않습니다. 다음은 보고서 제출 양식에서 요청할 수 있는 항목의 예입니다.
제목: [문제에 대한 1줄의 설명을 추가하세요(예: 'mail.example.com에서의
XSS
세션 도용의 결과']
1.
2.
3.
공격 시나리오 및 영향: [어떻게 악용할 수 있나요? 이
문제가 보안에 어떤 영향을 미치나요?]
해결 조언: [원하는 경우 이 문제의 해결 또는 해결 방법에 관한 조언이 있으면 여기에 추가하세요.]