준비

이 섹션에서는 발견한 격차를 메우는 방법에 관한 실용적인 조언을 포함하여 조직에서 성공적인 취약점 공개 프로그램을 시작하고 운영하기 위해 준비하는 방법을 자세히 설명합니다.

버그 찾기

외부 보안 연구원과 기존 보안 프로그램을 보강하는 것은 복잡한 문제와 알 수 없는 취약점을 찾는 좋은 방법입니다. 하지만 VDP를 사용하여 내부적으로 찾을 수 있는 기본적인 보안 문제를 찾는 것은 리소스 낭비입니다.

확장 소재 관리

버그를 찾을 때 어디서부터 시작해야 할지 알 수 있는 유일한 방법은 버그에 대한 좋은 아이디어가 있어야만 합니다. 100개의 보안 도구를 구입할 수 있지만 팀이 모르는 사이에 애플리케이션, 시스템, 서비스를 즉석에서 준비하고 있는 경우, 특히 이러한 애셋에 대한 보안 평가를 검색하고 수행할 방법이 없는 경우에는 아무런 영향이 없습니다. 새로운 애플리케이션, 시스템 및 서비스를 구축하는 데 도움을 줄 책임이 있는 개인과 팀이 가동 중인 항목과 소유자에 관한 인벤토리를 생성하고 유지관리하기 위한 프로세스가 마련되어 있는지 확인합니다. 현재 프로세스가 없는 경우 이러한 팀과 협력하여 프로세스를 구축할 수 있는 좋은 기회입니다. 공격 표면을 파악할 때는 먼저 조직의 애셋을 이해하는 것이 가장 좋습니다. 이 프로세스의 일부로 보안팀은 보안 검토를 제공하기 위한 새로운 인프라 구현 개발에 참여해야 합니다. 방대한 자산과 소유자 인벤토리를 보유하는 것이 좋습니다. 이러한 종류의 인벤토리는 특정 시스템을 일시적으로 종료해야 하는 새 패치를 적용할 때 유용합니다. 정보를 제공해야 하는 개인이나 팀과 영향을 받는 시스템의 로드맵을 제공합니다. 강력한 애셋 관리 프로세스가 갖추어지면 프로세스 초기에 소유자를 식별하고 정기적으로 업데이트하며 조직 전체의 모든 시스템이 의도한 대로 작동할 수 있습니다.

선제적 애셋 관리 외에도 조직에 속하지만 표준화된 애셋 관리 프로세스의 결함을 뚫은 애셋을 식별하기 위해 구현할 수 있는 사후 대응 조치를 고려하세요. 여기에는 VDP 및 버그 바운티 프로그램에 참여하는 보안 연구원이 사용하는 것과 동일한 '정찰' 프로세스를 사용하는 것이 포함될 수 있습니다. 예를 들어 조직에 속할 수 있는 인터넷 연결 IP 범위 또는 도메인을 스캔하고 열거하는 무료 오픈소스 도구를 활용할 수 있습니다. Google에서 버그 바운티 정찰을 검색하면 다양한 도움말 및 유용한 정보를 얻을 수 있으므로 알지 못했던 조직의 애셋을 식별할 수 있습니다.

기본 취약점 스캔

이제 보안 문제를 찾아야 하는 위치를 확고히 했으므로 실제로 방법을 살펴보겠습니다. 조직의 리소스에 따라 다양한 수준의 심층 분석을 진행할 수 있지만 취약점 공개 프로그램을 통해 내부 보안 노력과 외부 해킹 커뮤니티 간의 균형을 찾아야 합니다. 이 균형은 사용 가능한 리소스에 따라 조직마다 다릅니다.

도구 선택

취약점을 파악하는 데 도움이 되는 다양한 도구가 있습니다. 일부 취약점 스캔 도구는 무료로 사용할 수 있지만, 비용이 드는 도구도 있습니다. 개인의 필요에 따라 알맞은 도구를 선택할 수 있습니다.

• 조직의 요구사항
• 각 도구가 이러한 요구사항을 얼마나 잘 충족하는지
• 도구의 이점이 비용 (재무 및 구현)을 능가하는 경우

이 요구사항 템플릿(OpenDocument .ods, Microsoft Excel .xlsx)을 사용하여 요구사항에 따라 다양한 도구를 평가할 수 있습니다. 템플릿에는 요구사항 예시가 몇 가지 포함되어 있지만 필요한 기능에 맞게 보안, IT, 엔지니어링팀과 논의해야 합니다. 취약점 공개 프로그램을 출시하기 전에 최소한 외부에 노출된 애셋(예: 웹사이트, API, 모바일 앱)에 대해 취약점 스캔을 실행할 수 있어야 합니다. 이렇게 하면 외부 보안 연구원을 초대하여 이러한 애셋 및 서비스를 테스트하기 전에 쉽게 발견할 수 있는 취약점을 찾아 해결할 수 있습니다.

스캔 설정

자동화된 취약점 스캔은 많은 문제를 발견할 수 있지만 거짓양성을 발생시킬 수도 있습니다. 따라서 영향을 받는 팀과 결과를 공유하기 전에 결과를 검증할 리소스를 확보해야 합니다. 스캔이 정기적으로 실행되고 이러한 스캔의 결과가 실제로 처리되도록 하는 프로세스를 구현해야 합니다. 이는 조직마다 다르게 보이지만 최소한 다음을 파악해야 합니다.

• 검색 빈도
  • 연속
  • 매주
  • 매월
• 스캔 중인 애셋
• 사용자 인증 정보
  • 인증된 스캔과 인증되지 않은 스캔의 비교
  • (힌트: 사용자 인증 정보로 스캔하지 않으면 VDP를 시작할 때 보안 연구원이 사용자 인증 정보로 테스트하면 식별된 취약점이 급증할 수 있습니다.)
• 역할 및 책임
  • 스캔 실행을 담당하는 팀원 식별
  • 필요한 경우 순환 설정
• 스캔 결과
  • 스캔 결과 확인
  • 확인된 취약점에 대한 버그 제출
  • 버그 수정을 위한 소유자 식별
  • 해결과 관련해 소유자와 후속 조치

식별된 보안 문제가 해결되었는지 확인하는 방법은 이 가이드 뒷부분의 버그 수정 섹션에서 자세히 설명합니다.

보안 검토 프로세스

취약점 스캔은 조직의 보안 문제를 사후에 식별할 수 있는 좋은 방법이지만 보안 검토 프로세스를 구현하면 취약점이 애초에 발생하는 것을 방지하는 데 도움이 될 수 있습니다. 이 가이드에서 보안 검토라는 용어는 보안팀 구성원의 수동 검토를 트리거하는 모든 상황을 의미합니다. 일반적으로 너무 위험하다고 간주되는 변경을 차단할 수 있는 권한이 포함됩니다. 보안팀에 위험한 변경사항을 차단할 수 있는 권한이 없더라도 위험을 문서화하는 프로세스를 마련하는 것이 좋습니다. 이를 통해 변경을 추진하는 사람이 관련 위험을 인지하고 이러한 위험을 사전에 용인할 수 있습니다.

보안 검토 기준

보안 검토는 언제 진행해야 하나요? 보안 검토를 트리거하는 기준 집합을 만들면 모든 사람이 같은 정보를 파악할 수 있습니다. 다음은 보안 검토를 트리거할 수 있는 시나리오의 예입니다.

• 민감한 사용자 데이터와 관련된 새로운 기능이 제안됨
  • 사용자가 지도에서 위치를 공유할 수 있는 새로운 기능
  • 집 주소, 생년월일, 전화번호와 같은 민감할 수 있는 정보를 사용자에게 요청
• 기존 기능에 대한 주요 업데이트가 이루어집니다.
  • 기존 사용자 데이터를 가져와 사용자가 예상할 수 없는 새로운 방식으로 이용하지만 사용자에게 거부할 기회를 주지 않음
  • 인증, 승인, 세션 관리와 관련된 기능 변경사항
• 회사의 프로덕션 환경 변경
  • 네트워크 구성 변경사항(특히 서비스를 외부에 노출할 수 있는 변경사항)
  • 민감한 사용자 데이터를 처리하는 새 소프트웨어 설치(손상 시 간접적으로 민감한 사용자 데이터에 액세스하는 데 사용될 수 있음)
  • 새로운 시스템 또는 서비스 구축
• 새로운 공급업체와 상호작용 또는 기존 공급업체와 작업 방식 변경
  • 민감한 사용자 데이터를 처리할 새로운 공급업체 온보딩
  • 기존 공급업체와 작업하는 방식의 변경으로 인해 공급업체에서 민감한 사용자 데이터를 처리하는 방식 변경

이 목록은 전체 목록은 아니지만 보안 검토가 필요한 변경사항에 대해 생각해 볼 수 있습니다. 보안 검토가 필요한 사항과 필요하지 않은 사항에 대한 기준을 정의할 때 조직 전체의 주요 이해관계자와 논의하여 다음을 확인합니다.

• 이해관계자는 이 행사의 기준에 관해 검토하고 피드백을 제공할 수 있으며
• 이해관계자가 기준에 동의
• 이해관계자들은 선제적으로 보안 검토를 요청하는 데 동의

이 기준과 보안 검토를 요청하는 방법 (예: 보안팀이 모니터링하는 대기열에 버그 제출)을 문서화하여 조직에서 이 프로세스를 최대한 쉽게 따를 수 있도록 합니다.

보안 검토 리소스

자동 스캔과 달리 보안 검토는 리소스 집약적일 수 있습니다. 모든 보안 팀은 하루 중 수많은 작업을 처리하는 시간이 많기 때문에 사용자의 기준에 따라 몇 번의 보안 검토가 생성될지 추정해야 합니다. 팀이 과부하 상태이고 뒤처진다면 기능 출시를 기다리는 팀원은 보안팀에 불만을 느끼게 됩니다. 이로 인해 조직의 문화적 변화로 인해 보안팀이 파트너가 아닌 방해 요인으로 여겨질 수 있습니다. 보안 검토 프로세스가 효율적이지 않으면 많은 개인과 팀이 보안 검토 프로세스를 완전히 우회하려고합니다. 리소스가 빠듯하다면 보안 검토를 요구하는 기준을 느슨하게 하고 더 많은 잔존 위험을 감수하는 것이 좋습니다. 보안 검토를 수행할 리소스가 부족하여 이슈가 발생하는 경우, 더 많은 보안 리소스의 필요성을 정당화하는 데 도움이 됩니다.

보안 검토 수행

수행할 보안 검토 및 수행 방법을 결정할 때 가져올 우선순위가 지정된 큐가 필요합니다. 조직의 다른 사용자가 적절한 우선순위를 지정하는 데 필요한 모든 정보를 사용하여 보안 검토를 요청할 수 있는 표준화된 방법을 만듭니다. 예를 들어 변경사항의 간략한 요약과 영향을 받을 수 있는 사용자 데이터의 유형 등 변경사항의 특성과 같은 항목이 포함된 설문지를 고려해 보세요. 이러한 질문에 대한 답변에 따라 잠재적인 보안 검토를 높음, 중간, 낮은 위험 변경사항으로 자동 분류할 수 있습니다. 변경 위험이 높은 경우 보다 심층적인 보안 검토 프로세스가 필요할 수 있습니다. 변경사항이 위험도가 낮은 경우 더 간단한 보안 검토 프로세스를 구현하여 필요한 리소스를 줄이고 프로세스를 가속화하여 비즈니스를 더 효율적으로 지원할 수 있습니다. 팀 내에서 보안 검토 큐를 관리하고, 팀 구성원이 새로운 보안 검토를 선택할 수 있도록 하며, 기존 보안 검토 진행 상황에 대한 후속 조치를 담당하도록 팀 내에서 순환을 설정하는 것이 좋습니다. 실제 보안 검토 프로세스는 조사 대상에 따라 다릅니다. 예를 들어 모바일 앱의 새 기능을 사용하려면 보안 엔지니어가 코드를 검토하고 잠재적인 취약점을 찾아야 할 수 있습니다. 설치 중인 새 소프트웨어를 검토하여 액세스 제어가 적절하게 설정되었는지 확인해야 할 수 있습니다. 외부 공급업체와 작업할 경우 완전히 다른 프로세스가 나타날 수 있습니다. 자세한 내용은 Google의 공급업체 보안 평가 설문지를 읽어보세요.

버그 수정

버그를 찾는 것도 중요하지만 버그가 수정된 후에야 보안이 향상됩니다. 조직에 어떤 위험이 존재하는지 아는 것이 좋지만 위험을 효율적으로 해결할 수 있다면 더 좋습니다.

취약점 관리

취약점은 내부 작업(예: 취약점 스캔 및 보안 검토), 서드 파티 침투 테스트 및 감사, 심지어 VDP가 공식 출시되기 전에 지원 채널을 통해 알리는 외부 보안 연구자 등 다양한 리소스에서 비롯됩니다. 조직에는 새로운 취약점과 기존 취약점이 적절한 이해관계자에게 전달되고, 올바른 우선순위가 지정되며, 시의적절한 방식으로 수정되도록 하기 위해 새로운 취약점과 기존 취약점을 분류할 방법이 필요합니다. VDP를 출시하면 취약점 관리 프로세스에 새로운 취약점 흐름이 발생합니다. 이러한 취약점 처리를 위한 견고한 프로세스가 마련되어 있으면 해결 진행 상황을 추적하고 외부 보안 연구원의 업데이트 요청에 대응하는 데 도움이 됩니다. 신속하게 취약점의 우선순위를 정하고 VDP 참여자와 해결 일정에 관해 소통할 수 있으면 보안 연구원 커뮤니티의 참여도가 높아지고 조직의 보안 평판이 향상됩니다. 다음 섹션에서는 VDP를 출시하기 전에 마련할 취약점 관리 프로그램의 다양한 측면을 간략히 설명합니다.

심각도 표준 및 해결 일정 수립

취약점의 심각도에 관한 공통된 표현과 각 심각도와 관련된 이상적인 해결 일정을 만들면 조직의 표준 기대치를 더 쉽게 설정할 수 있습니다. 모든 취약점이 긴급 상황처럼 취급되면 조직에서 리소스가 고갈되고 보안팀에 대한 분노가 커질 것입니다. 모든 취약점이 낮은 우선순위로 간주되면 취약점이 수정되지 않으며 침해 위험이 커집니다. 모든 조직은 리소스가 제한되어 있으므로 심각도 순위를 설정해야 합니다. 이 순위는 조직에서 취약점이 해당하는 심각도와 각 심각도와 관련된 예상 해결 일정을 파악하는 데 도움이 되는 기준을 제공합니다. 심각도 가이드라인의 초안을 작성하고 조직의 주요 이해관계자와 공유하여 의견을 수렴합니다. 예를 들어 엔지니어링이 심각도 표준을 만드는 경우 이러한 표준을 승인하고 지정된 기간 내에 취약점을 수정할 때가 되면 이를 준수할 가능성이 높습니다. 이러한 심각도 가이드라인은 비즈니스의 특정 위험에 따라 달라질 수 있습니다. 조직에 가장 적합하고 영향을 미치는 위협이 무엇인지 생각해 보고 각 심각도 카테고리에 속하는 문제의 예를 포함하는 위협 모델링 연습을 고려할 수 있습니다. 다음은 금융 조직의 심각도 표준 및 해결 타임라인의 예입니다.

심각도	설명	해결 타임라인	예시
심각	Google 사용자 또는 비즈니스에 위급한 위협을 가하는 문제	소유자: 취약점 해결을 담당하는 기본 소유자를 8시간 이내에 지정해야 합니다. 정규 업무 시간이 아닐 때도 필요에 따라 리소스를 호출합니다. 해결 방법: 가능한 한 빨리 또는 최대 3일(영업일 기준) 이내에 문제 자체를 해결하거나 적어도 위험을 완화해야 합니다.	모든 사용자의 재무 레코드를 포함하는 프로덕션 데이터베이스의 손상 공격자가 Google의 독점 투자 알고리즘과 같은 영업 비밀에 대한 액세스 권한을 획득합니다. 공격자가 내부 네트워크 또는 민감한 프로덕션 시스템에 대한 액세스 권한을 확보하는 등 활성 상태인 이슈
높음	악용될 경우 심각한 피해를 일으킬 수 있는 문제	소유자: 기본 소유자는 영업일 기준 1일 이내에 지정되어야 합니다. 해결 방법: 영업일 기준 10일 (~2주) 이내	민감한 사용자 데이터 또는 기능에 액세스할 수 있는 취약점 (예: 모든 사용자가 다른 사용자의 돈을 훔칠 수 있는 기능)
보통	악용하기 어렵거나 직접적인 피해를 초래하지 않는 문제	소유자: 기본 소유자는 영업일 기준 5일 이내에 지정되어야 합니다. 해결 방법: 영업일 기준 20~40일 (약 1~2개월) 이내입니다.	자동화된 스캐너로 식별된 확인된 문제입니다(예: 알려진 악용이 없는 보안 업데이트 패치). 추가 공격에 도움이 될 수 있는 정보 공개 문제 악용될 수 있는 비율 제한 문제 (예: 사용자의 비밀번호를 지속적으로 추측하는 기능)
낮음	영향이 적은 문제이며 주로 알려진 문제를 로깅하는 데 사용됩니다.	지정된 타임라인 내에서 소유자를 찾거나 문제를 해결하기 위한 요구사항이 없습니다.	위험은 없지만 외부에서 정보에 액세스할 필요가 없는 정보 공개

그루밍 버그

여기서는 머리를 자르는 것이 아니라 버그의 형식을 올바르게 지정하여 쉽게 수정할 수 있도록 하는 것입니다. 위 표를 가이드라인으로 사용하여 자체 심각도 정의를 설정합니다. 이러한 정의는 버그를 다양한 심각도로 분류하고 소유자에게 전달하는 데 사용됩니다.

각 취약점에 심각도를 할당하는 것 외에도 버그가 수신 팀에서 더 쉽게 처리할 수 있는 표준 형식인지 확인해야 합니다. 취약점은 자동 스캐너 결과 또는 보안 검토의 수동 작성과 같은 다양한 형식으로 취약점 관리 프로세스에 침투합니다. 각 취약점을 표준 형식으로 변환하는 데 시간을 할애하면 전달받는 팀이 문제를 빠르게 이해하고 해결할 수 있는 가능성이 높아집니다.

이 형식이나 템플릿은 조직에 따라 다를 수 있으며 소유자가 할당된 버그를 수정하는 데 가장 도움이 되는 정보가 무엇인지에 따라 달라질 수 있지만 다음은 사용할 수 있는 템플릿 예입니다. 나중에 연구원을 위한 취약점 공개 프로그램 제출 양식을 만들 때 이 템플릿을 재사용할 수 있습니다.

제목: <문제에 대한 한 줄 설명, 일반적으로 해결 시나리오 또는 해결 방법: 취약점 유형, 영향을 받는 애셋/서비스 등. 필요에 따라 심각도를 포함하거나 문제 추적기의 필드에 심각도를 매핑

다음은 심각도가 높은 취약점의 예입니다.

제목: [HIGH] 프로필 페이지의 안전하지 않은 직접 객체 참조(IDOR) 요약: 앱의 프로필 페이지 기능에서 IDOR이 발견되었습니다. 이 ID로 인해 다른 사용자의 전체 이름, 집 주소, 전화번호, 생년월일 등 다른 사용자의 프로필을 보고 수정할 수 있는 무단 액세스 권한을 부여받을 수 있습니다. 로그를 검토한 결과 이 문제는 아직 악용되지 않은 것으로 보입니다. 이 문제는 내부적으로 발견되었습니다. 재현 단계:

1. 앱이 설치된 휴대기기의 트래픽을 가로채도록 프록시(예: Burp 도구 모음)를 설정합니다.
2. 프로필 페이지를 방문하여 연결된 HTTP 요청을 가로챕니다.
3. profileID=######을 profileID=000000 (테스트 사용자)이 되도록 수정하고 HTTP 요청과 함께 전송합니다.
4. 앱에 사용자 000000의 프로필이 표시되며 이 사용자의 정보를 보고 수정할 수 있습니다.

공격 시나리오 / 영향: 모든 사용자가 이 취약점을 사용하여 다른 사용자의 프로필을 보고 수정할 수 있습니다. 최악의 경우 공격자가 전체 시스템에서 모든 사용자의 프로필 정보를 가져오는 프로세스를 자동화할 수 있습니다. 이 문제는 아직 악용되지 않았다고 생각하지만 심각도가 높은 일반적인 문제로 취급하는 것이 중요합니다. 악용의 증거가 발견될 경우 심각한 심각도로 에스컬레이션될 수 있습니다. 해결 단계: 요청을 보내는 사용자에게 profileID의 값을 통해 요청된 프로필을 보거나 수정할 수 있는 액세스 권한이 있는지 확인하려면 서버 측 검사를 구현합니다. 예를 들어 윤아가 로그인했고 profileID 123456을 가지고 있지만 profileID 333444를 요청한 것으로 확인되는 경우 사용자에게 오류가 표시되고 다른 사용자의 프로필에 액세스하려는 시도가 기록되어야 합니다. IDOR에 관한 자세한 내용 및 해결 방법은 이 버그에 관한 OWASP 자료를 참고하세요.

다양한 소스의 취약점을 표준 형식으로 자동화하는 방법을 찾아 시간과 수작업을 줄일 수 있습니다. 더 많은 취약점이 발생하면 해결 단계에서 일반적인 주제를 찾을 수 있습니다. 일반적인 버그 형식 템플릿 외에도 일반적인 취약점 유형을 위한 추가 템플릿을 만들 수 있습니다.

소유자 찾기

취약점 관리에서 가장 어려운 점 중 하나는 버그 수정을 도와줄 소유자를 식별하고, 일정에 따라 실제로 버그를 수정하는 데 리소스를 투입하도록 하는 것입니다. 애셋 관리 프로세스를 설정한 경우 이 작업이 조금 더 쉬워집니다. 그렇지 않다면 주인을 찾을 동기가 될 수 있습니다. 조직의 규모에 따라 소유자를 찾는 것이 꽤 간단할 수도 있고 엄청나게 복잡할 수도 있습니다. 조직이 성장함에 따라 새로 발견된 보안 문제를 해결할 담당자를 결정하는 노력도 증가합니다. 작업 중 순환을 구현하는 것이 좋습니다. 근무 중인 사람은 누구나 할당되지 않은 취약점을 검토하고 소유자를 추적하며 심각도에 따른 우선순위를 정할 책임이 있습니다. 취약점 수정 담당자를 식별하고 버그에 할당할 수 있더라도 실제로 문제를 해결하는 데 시간을 투자하도록 설득해야 합니다. 이 접근 방식은 팀 또는 개인, 작업 중인 기타 항목에 따라 다를 수 있습니다. 심각도 표준 및 해결 일정에 대한 조직적 승인을 얻었다면 이를 참조할 수 있지만 때로는 버그 수정을 위해 추가 설득이 필요할 수도 있습니다. 다음은 취약점 해결을 위한 일반적인 팁입니다.

• 이유 설명: 누군가에게 해결해야 할 취약점이 할당되는 것은 대체로 예상치 못한 작업입니다. 이 문제가 시기적절하게 해결하는 것이 중요한 이유 (예: 영향 / 공격 시나리오)를 설명하고 소유자가 이해할 수 있도록 합니다.
• 컨텍스트 수집: 경우에 따라 한 사람만 버그를 수정하는 데 필요한 지식을 가지고 있고 현재 작업 중인 다른 작업이 있을 수 있습니다. 잠시 시간을 내어 이러한 취약점을 파악하세요. 단기적으로 이 취약점을 해결하는 것보다 다른 작업이 더 중요할 수도 있습니다. 해결 일정에 대해 공감과 유연성을 보여주면 호의를 얻고 취약점 해결에 필요한 사람들과의 관계를 강화할 수 있습니다. 지나치게 많은 여지를 주지 않도록 주의하세요. 지나치게 여유를 주지 마세요. 그러지 않으면 조직에서 해결 일정을 중요하게 여기지 않을 것입니다.
• 방법 설명: 버그에 해결 조언을 포함하더라도 문제 해결 책임자가 혼란스러워하거나 버그 수정 방법을 알아보는 데 도움이 필요할 수 있습니다. 해결 방법을 찾는 데 도움이 필요하다면 가르쳐 주세요. 소유자에게 도움을 주지 않고 단순히 버그만 남기는 것만으로는 조직과 보안팀과의 관계에 악영향을 미칠 수 있습니다. 다른 사람을 가능한 한 많이 도와주면 그들이 현재와 미래의 취약성을 수정하고 다른 사람을 가르치는 데에도 도움이 됩니다.
• 요청 조정: 다양한 팀과 개인은 들어오는 작업 요청을 수락하고 우선순위를 지정하는 방식에 대한 기존 프로세스가 있을 수 있습니다. 일부 팀은 수신되는 모든 요청이 관리자를 통해 전달되도록 할 수 있습니다. 표준 형식으로 제출되기를 원하는 지원 요청도 있습니다. 일부는 스프린트에 사전 정의된 것에서만 작동합니다. 어떤 경우든 팀이나 개인이 도움을 받기 위해 일반적으로 사용하는 형식에 맞게 요청을 조정하면 요청의 우선순위가 지정되고 조치가 취해질 가능성이 높아집니다.
• 최후의 수단으로 에스컬레이션: 위의 모든 방법을 시도했지만 취약점 해결 담당자나 팀이 심각한 보안 문제를 해결하는 데 시간을 들이지 못할 경우 필요에 따라 리더로 에스컬레이션하는 것이 좋습니다. 이 방법은 해당 개인 또는 팀과의 관계에 해가 될 수 있으므로 항상 최후의 수단으로 사용해야 합니다.

근본 원인 분석

개별 취약점을 찾고 수정하는 것 외에도 근본 원인 분석 (RCA)을 수행하면 시스템 보안 문제를 식별하고 해결할 수 있습니다. 사람마다 리소스가 제한되어 있으므로 이 단계를 건너뛰는 것이 좋습니다. 하지만 취약점 데이터의 트렌드를 분석하고 심각도가 높은 버그를 자세히 살펴보는 데 시간을 투자하면 장기적으로 시간을 절약하고 위험을 줄일 수 있습니다. 예를 들어 앱 전체에서 동일한 취약점 유형 (예: 인텐트 리디렉션)이 계속해서 나타난다고 가정해 보겠습니다. 이 취약점을 앱에 도입하는 팀과 이야기해 보기로 했으며, 이들 중 대다수가 인텐트 리디렉션이 무엇인지, 왜 중요한지 또는 어떻게 방지해야 하는지 모른다는 사실을 알게 되었습니다. 이 취약점에 대해 조직의 개발자에게 교육하는 데 도움이 되는 강연과 가이드를 마련했습니다. 이 취약점이 완전히 사라지지는 않을 수도 있지만, 취약점이 나타나는 속도는 감소할 가능성이 있습니다. VDP를 출시할 때 서드 파티가 보고하는 모든 취약점은 기존 내부 보안 프로세스를 통과합니다. VDP의 버그에 RCA를 실행하면 보안 프로그램을 체계적으로 개선하는 방법에 대한 유용한 정보를 더 많이 얻을 수 있습니다.

감지 및 대응

감지 및 대응이란 조직을 상대로 한 잠재적 공격을 감지하고 이에 대응하기 위해 사용 중인 모든 도구와 프로세스를 의미합니다. 이는 데이터를 분석하여 의심스러운 행동을 식별하는, 구매 또는 자체 개발한 솔루션의 형태로 제공될 수 있습니다. 예를 들어 그루밍 버그 섹션에서 사용자가 다른 사용자의 프로필에 무단으로 액세스하려고 할 때마다 로깅하는 것에 관해 이야기했습니다. 사용자가 단기간에 다른 사용자의 프로필에 액세스하려는 시도를 여러 번 실패하는 경우 생성되는 신호 또는 알림이 있을 수 있습니다. 특정 기간 동안 또는 상황을 검토하고 수동으로 액세스를 복원할 수 있을 때까지 무기한으로 해당 사용자가 서비스에 액세스하지 못하도록 차단하는 프로세스를 자동화할 수도 있습니다. 아직 감지 및 대응 메커니즘을 갖추지 않은 경우 전문 컨설턴트와 협력하여 조직의 디지털 포렌식 및 사고 대응 (DFIR) 프로그램을 빌드하는 방법을 알아보세요. 감지 및 대응 메커니즘이 이미 마련되어 있다면 5명, 10명 또는 100명의 보안 연구원이 인터넷 연결 공격 표면에 대해 테스트하게 될 결과를 고려해야 합니다. 이는 사용 중인 모든 IDS/IPS (침입 감지 및 방지 시스템)에 큰 영향을 미칠 수 있습니다.

잠재적 위험은 다음과 같습니다.

• 알림 과부하: 악의적인 공격처럼 보이지만 실제로는 VDP에 참여하는 보안 연구원의 정상적인 승인된 테스트인 알림 또는 신호가 넘쳐나는 현상입니다. 노이즈가 너무 많이 생성되어 실제 공격과 합법적인 보안 테스트를 구분하기가 어려워집니다.
• 사고 대응 거짓 경보: 토요일 오전 2시에 개인을 호출하는 프로세스가 있는 경우 사용자는 일어나서 실제로 적법한 테스트를 수행하는 보안 연구원이었던 잠재적 보안 침해를 조사하는 것에 만족하지 않을 것입니다.
• 보안 연구원 차단: 공격적인 IPS(침입 방지 시스템)를 사용하면 취약점을 파악하고 보고하기 위해 스캔, 수동 테스트 등을 실행하려는 보안 연구원의 IP 주소를 차단하게 될 수 있습니다. 특히 VDP의 경우 테스트 5분 후 보안 연구원이 차단되면 관심을 잃고 대신 다른 조직의 프로그램에 집중할 수 있습니다. 이로 인해 전반적인 보안 연구자의 프로그램 참여가 부족해질 수 있으며, 이로 인해 취약점이 발견되지 않은 상태로 남아 조직에서 알려지지 않을 위험이 커집니다. IPS 자체의 강도를 낮추고 싶지는 않을 수 있지만 연구원의 연결 해제 위험을 완화하기 위해 취할 수 있는 다른 조치가 있습니다.

이러한 위험을 해결하는 방법은 주로 외부 보안 연구원과 작업할 때 사용할 접근 방식에 따라 달라집니다. 실제 공격을 시뮬레이션하는 보다 블랙박스 스타일의 테스트를 원한다면 아무런 조치를 취하지 않아도 됩니다. 이 경우 연구원의 트래픽이 알림을 생성하며 팀에서 적절하게 조사하고 대응하기 위한 조치를 취할 수 있습니다. 이렇게 하면 팀이 실제 공격처럼 보이는 것에 대응하는 연습을 할 수 있지만, 특히 테스트에서 차단된 보안 연구원의 참여도가 감소할 수 있습니다. 또한 합법적인 테스트를 조사하는 동안 실제 공격을 누락할 수도 있습니다. 회색 상자 접근 방식을 더 원한다면 보안 연구원과 협력하여 어떤 식으로든 테스트 트래픽을 자체 식별할 수 있습니다. 이렇게 하면 테스트 및 결과 알림을 통해 트래픽을 허용 목록에 추가하거나 다른 방식으로 필터링할 수 있습니다. 팀이 실제 공격을 승인된 테스트와 더 잘 구별할 수 있으며 연구원은 침입 방지 시스템에 의해 방해를 받지 않고 취약점을 찾아 보고할 수 있습니다. 일부 조직은 보안 연구원에게 양식을 제출하여 연구자가 생성한 요청의 헤더에 첨부할 수 있는 고유 식별자를 신청할 것을 요청합니다. 이를 통해 조직은 연구자의 트래픽을 허용할 수 있을 뿐만 아니라 연구원이 합의된 테스트 범위를 벗어나기 시작했는지 식별할 수 있습니다. 이러한 상황이 발생하면 연구원에게 연락하여 함께 테스트 계획을 세울 수 있을 때까지 보류하도록 요청할 수 있습니다.